In a digital packet-switched communications network different types of traffic, e.g. voice, data, audio and video, may be conveyed between multiple parties via shared resources, e.g. routers or transmission channels. Some traffic, such as many audio and video applications, typically occurs in real time, whereas other traffic, such as many data applications, typically is not in real time. The traffic generated by different types of applications may be data packets that are transmitted from sending nodes to receiving nodes in sessions that may be set up over communication links or connection paths through the communications network.
When the traffic load in the communications network gets too high, congestion may occur. Congestion means that the data packets are sent by the sender or sending node faster than the packets can be transferred on the connection path to the receiver or receiving node. Congestion can have multiple causes. For example radio link level congestion may be caused by too high traffic load in the cell, whereas transport network link congestion may be caused by too high load on a particular link in the transport network. Congestion can also occur when a user equipment (UE) moves towards the cell edge and becomes coverage limited.
As a consequence of the congestion, the packet queue length in the buffer of a sending node that sends packets on a congested communications link starts increasing which may lead to packet drops when the buffer's maximum queue length is reached or when the queuing time in the buffer exceeds a certain limit.
To alleviate the congestion, congestion control mechanisms may be employed to control the rate of rate adaptive sources or applications based on congestion indications. The congestion control mechanisms control the rate adaptive sources or applications so that they drop or reduce the rate at which packets are sent during congestion and restore the rate when the congestion is over. A congestion indication can be based on measurements of queuing delay of packets in a congested node or resource. The congestion may then be indicated to the receiver or receiving node by means of special signaling like Explicit Congestion Notification (ECN) bits in the Internet Protocol (IP) header of the data packets. Alternatively, congestion may be detected at the receiver or receiving node based on jitter level. Congestion may also be detected based on packet loss, but using packet loss as the main source for detecting congestion may not be acceptable for real-time media applications like voice and video, as these applications are delay-sensitive and also quite sensitive to packet loss. There is then a risk that the application has already stopped working when congestion is detected.
There are not many widely agreed upon and standardized congestion control algorithms. Besides congestion control algorithms intended for Transmission Control Protocol (TCP), the most known algorithms are TCP-like congestion control algorithms, specified for Datagram Congestion Control Protocol (DCCP) in Internet Engineering Task Force (IETF) Request for Comments (RFC) 4341, and TCP-friendly Rate Control, specified in IETF RFC 3448.
TCP uses an Additive Increase Multiplicative Decrease (AIMD) algorithm where a length of a congestion window is used for congestion control. The length specifies a maximum number of packets, or segments of packets, that may be sent by a TCP sender or sending node without receiving feedback from the TCP receiver or receiving node. At congestion the AIMD algorithm applies a decrease-to-half strategy, wherein the length of the congestion window is reduced to half its original size. After that congestion has occurred an increase-by-one strategy is applied, wherein the length of the congestion window is increased by one packet at a time until the length of the window is restored.
As a general principle, the TCP-friendly Rate Control algorithms model the TCP congestion control behavior so that they are TCP-friendly on a longer term but behave differently on a short term. Usually the intention is to smooth the rate change intensity or steps at which the rate is changed for applications that need a rate change at an even pace for their performance. This is because the TCP congestion window only sets a maximum limit for the number of packets that may be sent without receiving feedback, but it does not specify a target rate at which the packets should be sent by the sender or sending node.
Unfortunately, the TCP-friendly Rate Control algorithms emphasize packet loss as a main source for detecting congestion. As a result, these algorithms allow quite high packet loss during congestion. Such a behavior is not suitable for real-time media applications such as voice and video applications. Additionally, the origin of the packet loss might not be congestion but a non-congestive packet loss caused by bad quality, e.g. of a radio link.
The working principle of real-time friendly congestion control algorithms resembles the working principle of TCP or TCP-friendly algorithms; but instead of using packet loss as an indicator for detecting congestion they are using “soft” congestion indicators such as packet jitter or ECN indication triggered by queuing delay as earlier described.
The real-time friendly congestion control mechanisms usually incur fast rate drop or reduction when congestion is indicated and slow rate increase when the congestion is over. The rate is dropped or reduced fast when congestion is indicated or detected in order to avoid packet loss. Implementation of fast rate drop is quite straight forward and there are many proposed solutions on how to do that in an adaptive way. How to increase the rate when the congestion ceases is more problematic.
A problem is how to determine when there is room for increasing the rate again. Increasing the rate too much too early will cause oscillations in rate, as the rate may then have to be dropped again due to that the congestion has not yet ceased. To alleviate the oscillation during congestion the rate should be increased very slowly.
However, if the rate is increased slowly during a longer period than necessary the link utilization will not be efficient and the time until good connection quality is restored after that the congestion is over will be longer than necessary. Therefore, the rate increase should be fast when the congestion ceases. Conventional congestion control mechanisms therefore typically increase the rate with constant or close to constant speed, where the speed of the rate increase is set as a compromise between these different requirements.
This means that, with existing congestion control mechanisms, either the rate oscillations during congestion are quite high, which reduces the connection quality, or the rate is increased too slowly after that the congestion is over, which means that the available link capacity is not fully utilized and the delay until good connection quality is restored is unnecessarily long. Thus, it is a problem that an application that is running in a session between a sending node and a receiving node cannot know in advance whether to increase the rate at a slow pace or at a fast pace.